Travis-CI has been broken all week, as it seems...

TL;DR: @Seldaek as discussed personally last week, I did indeed think long and discussed with others about whether to release or not support for composer/composer 2.0.0-dev for this package in the 1.4.x branch: in the end, I will not do it.

For other readers that may not get the full context: there are two sides to this, a technical one, and a political one.

My release policy is indeed very strict:

• only bugfixes in patch releases
• no dependency changes in patch releases
• keep dependency ranges extremely small (ideally only "latest")
• backport fixes only if critical (security / broken release)

I didn't find a way to consider a bump to Composer 2.0.0 a "security issue" in the 1.2.x branch or 1.4.x branch, both still running on PHP 7.1.

That was the technical part.

The political is my unwillingness to do it, as I believe that the ecosystem continuously requires a push, and that's part of why I like maintaining the packages under the ocramius/ vendor: people using them are either lagging behind or get the best effort development quality that I can provide.

In general, I still believe that forcing (yes, I'm aware that I'm always pushing it) people to upgrade to latest stable is a much more viable strategy than trying to drag along people and mostly companies that are lagging behind.

I am aware that Packagist has an old API that will need to run for a lot of time (until composer 1.x is dead), but I would much rather see composer v2 to be 7.4+, instead of supporting every version that is still used in the wild: that's ultimately not my choice, and it is something we'll disagree upon.

This can still be supported in forks supporting older versions (heck, even PHP 5.3!), but won't be done under my watch.

Actually exactly this caused installation errors on all freshly booting systems running on top of Frontastic right now. Our build process automatically updated composer and with the existing lock files of our customers the package versions cannot be resolved any more.

We right now force composer to stay at 1.4 because of this in all customer repositories because we also cannot update their dependencies without proper testing.

It would be great to allow composer 2.*. This would have saved us a lot time of hotfixing the build processes for all customers.

@Ocramius Just one last consideration here from my side. Of course you can have your fun with your ocramius/* packages, but as this is depended on by Doctrine, it means all Doctrine users are exposed to your policies without having chosen that at all.

Also note that I did not ask you to support PHP 5.3, but IMO 7.2 isn't that unreasonable to ask for these days. It's not even EOL yet. I know I have a bunch of servers still using it until later this month when I can move to Ubuntu 20.04 LTS and move to php 7.4 at the same time.

Anyway my composer2-1.4 branch shall remain there, in case you change your mind.

but as this is depended on by Doctrine

Irrelevant: I know thousands of other packages depend on this, which is the point of me pushing such agendas.

Anyway, closing+locking, as I'm not intending to change this.

Authoritative response remains #133 (comment)

We right now force composer to stay at 1.4 because of this in all customer repositories because we also cannot update their dependencies without proper testing.

composer/composer is at 2.0-dev-stage right now, not for GA usage on end-customer projects.

That goes back to #105 (see end of thread).